To access the contents, click the chapter and section titles.
Oracle Performance Tuning and Optimization
(Publisher: Macmillan Computer Publishing)
Author(s): Edward Whalen
ISBN: 067230886x
Publication Date: 04/01/96
Chapter 4 Tuning Methodology
This chapter covers tuning methodologythe manner in which you analytically determine what it is you want to tune and for what ends. If you set out to tune or optimize a system without any goals, there is nothing to measure success against. The first part of the chapter looks at some of the tuning goals you might have; the second part of the chapter is an introduction to a tuning methodology that may help you in your tuning efforts.
Goals
It is important to set tuning goals for your system. Each system has deferent characteristics depending on the needs of the users. You must determine why you are tuning a particular system. The desired goals often influence the kind of changes made and whether those changes are successful or not. People tune their systems for different reasons; the following sections examine a few of them.
Throughput
Throughput is defined as the amount of work done divided by the time it takes to do that work. Work to be done is usually defined in terms of transactions. Therefore, the throughput of the system is defined as follows:
Throughput = #Transactions / Time
The time in this equation is usually some measurement interval during which a large amount of work is done. Consider, for example, a company that takes reservations. If the reservation office is open 8 hours a day and the number of tickets sold for an event must be 25,000 for first day of sales, the required throughput for this system must meet or exceed 3,125 transactions per hour:
Throughput = ( 25,000 Transactions / 8 hours ) = 3,125 Transactions per hour
or 52.1 Transactions per minute
Depending on the complexity of the transaction and the granularity of your measurements, you can express throughput in transactions per hour, transactions per minute, or transactions per second. For some large decision support system (DSS) applications, you may even measure throughput in transactions per day.
For your particular configuration, the most important tuning goal may be system throughput. In some environments such as OnLine Transaction Processing (OLTP), it may be vital to achieve the highest throughput possible, thus getting the most possible work through the system in the shortest possible time.
To achieve the highest possible throughput, you may have to make sacrifices in some areas such as response time and perhaps fault tolerance and recovery time.
Response Time
Response time is the time from when you press the last key for an input form until all the data has been displayed on the display device. Response time is essentially the time the end user spends waiting for the behind-the-scenes processing of the job.
Although some installations require the highest throughput possible, others may have strict response time criteria. In such an environment, slow response times usually mean customers waiting on a phone linethus keeping other customers on hold.
For installations that have strict response time criteria, you may have to tune the system differently. It may be necessary to run the system at a much lower throughput rate than it can handle or to delay batch jobs until off hours.
Connectivity
Connectivity (the ability to support connections to other systems or clients) may be an important factor in configuring and tuning your system. You may have to configure and tune your system to support large numbers of users in an effective manner. Additionally, you may have to incorporate sufficient capacity to support additional users. Such a system might be used for a business that requires additional employees at various peak times during the year.
To tune for large numbers of connections, memory can be a special concern. You must carefully plan for the memory requirements of these users and make sure that you dont exceed available resources during peak periods. This may mean that you have to configure extra memory into the system that is on stand-by for user connections. OS resources associated with network and user connectivity must be closely monitored.
You can determine the resources associated with these users experimentally. Try running the application with a specific number of users and monitor system resource usage. Increase the number of users and monitor the system again. Comparing the results will give you a fairly good idea of the amount of resources associated with each user.
TIP: When performing these types of tests, it is critical to take good notes. By logging configuration changes and their results, you can get a good idea of how those changes affect the system.
Fault Tolerance
For some installations, it is of the utmost importance that fault tolerance be employed in every aspect of the system. Any down time in such a system may be devastating. A site with high fault tolerance requirements may require frequent checkpoints and frequent backups.
Several tuning considerations come into play when fault tolerance is the highest priority. The disk subsystem should use some type of hardware Redundant Array of Inexpensive Disks (RAID) to protect against disk failures. The memory should be protected with advanced ECC memory. When uptime is critical, you may want to consider a redundant system, which you can use if the primary system fails.
Load Time
Some systems have a requirement that a certain amount of data must be loaded each night to be available for the next days processing. Usually, the load time is limited and it is essential that a specific amount of data be loaded within a certain time. Although the load time requirement can be met, doing so may be costly in terms of additional hardware that may be required.
In this situation, you may have to tune the I/O subsystem for load time. However, configuring for load time may affect the general performance of the system. By tuning for both load time and run time, you can minimize the affect.
NOTE: It is important to realize that your tuning goals and my tuning goals may not be the same. Depending on your installation, there may be drastic differences in configuration. Each site is different and serves a different function; each site must be analyzed individually.
|